The present invention relates to the routing of packet data over a network and, more specifically, to a system and method for multiplexing multiple calls onto a single or a few channels on an Packet Network.
Packet data networks transfer packet data between computers, IP telephones, video devices, computer telephony interface servers and other equipment. In a packet network, the stream of data from a data source is divided into variable or fixed length xe2x80x9cpacketsxe2x80x9d of data before it is sent over the network. The packets are then reassembled at the destination to regenerate the stream of data. Typically, the techniques of packetizing data may make more efficient use of the data transmission facilities than methods (e.g. real time applications) that use dedicated connections between each source and destination (e.g., conventional telephone switching systems).
To enable the network to route the packet data to the appropriate destination, information (referred to as a header) is added to the data for each packet. A typical header contains the address of the source, the address of the destination and more information on the content of the packet.
A header may include information for setting up the connection between the endpoints and it may include information used to determine whether the connection has failed. In addition, information that is used to ensure that the data was sent without any errors may also be imbedded in the header. In practice, the format of the packet header and other packet routing details are defined by a protocol.
One of the more popular packet network protocols is the TCP/IP (Transmission Control Protocol/Internet Protocol) suite of protocols. The Internet Protocol (xe2x80x9cIPxe2x80x9d) relates to the data networking functions of routing a packet through the network. IP defines a frame of data including an IP header and the associated data (the xe2x80x9cpayloadxe2x80x9d). The network forwards the packet based on the network address contained in the IP header.
IP does not provide data flow control or error control. These functions are left to the Transmission Control Protocol (xe2x80x9cTCPxe2x80x9d). Thus, applications ensure the integrity of the data being sent over the network by sending TCP massages to one another. These messages are encapsulated in the IP messages which, as discussed above, are primarily used for routing the data to the proper destination in the network.
Applications that can waive the rigorous flow and error control that TCP provides may instead use the User Datagram Protocol (xe2x80x9cUDPxe2x80x9d). In general, UDP provides simpler data transmission than TCP because there is not as much overhead associated with error control. Both TCP and UDP define a frame which includes an associated header.
A TCP/IP (or UDP/IP) frame thus consists of the IP header and its payload. The IP payload, in turn, consists of the TCP (or UDP) frame and its payload. The TCP (or UDP) payload consists of the data being transmitted. This data may include other protocol information (e.g., H.323 discussed below), depending on the application.
In a simple example of a TCP/IP-based application, two switches (e.g., gateways or routers), both of which are connected to the IP network, are connected to several terminals that are connected to another network (typically a switched circuit network or a packet network). For real-time call applications the terminals (e.g., telephones, computers or video devices) send and receive signals (e.g., voice or video signals or digital data) to and from the associated switch. As necessary, each switch converts the incoming (and outgoing) signals to (and from) the TCP/IP format.
To transfer data through the network, the switches first set up a connection. A connection may be established, for example, using a three-way handshake. Briefly, this operation involves the transmission of a series of synchronization signals and sequence numbers between the switches. In the TCP vernacular, this operation opens a TCP connection. The TCP connection is associated with a pair of TCP sockets, one for each of the two switches. Each socket consists of an IP address and a port.
Once a TCP connection is open, the switches simultaneously monitor their respective TCP ports to perform any necessary TCP control operations. These operations would include, for example, flow control, error detection and data retransmission, each of which is performed independently for each connection.
When the number of calls to be exchanged between the switches is large, the above setup and monitoring operations reduce the efficiency of the network and the switches. In particular, the switches need to open, maintain and close several connections per call. In addition the three-way handshake reduces the speed at which each connection may be set up. The monitoring operations and the memory allocation for each connection use a significant amount of the resources of the switches. The overhead associated with the headers reduces the data throughput. Also, the communications exchanged to open and close channels burden the network and reduce the available bandwidth. Thus, a need exist to improve the efficiency of data transfers in a packet-based network.
The invention provides a system and method for routing concurrent calls between switches connected to a wire-based, wireless or satellite packet network (e.g., a TCP/UDP/IP network). The incoming calls to the switches (e.g., those originating from the terminals connected to each switch) are multiplexed onto a single TCP or UDP channel (or relatively few channels as discussed below). Thus, the multiplexed calls are treated as a single connection. As a result, the switches do not allocate and set up individual TCP or UDP connections for each call. Instead, calls are established using a simplified connection setup procedure.
Prior to routing the calls, the switches set up a xe2x80x9cpermanentlyxe2x80x9d open TCP connection (and UDP connection, if necessary) between one another. This connection, referred to as an IP trunk, is permanent in the sense that it is not set up and torn down on a call-by-call basis. Instead, in general, it is set up to make the connection available for use (for example, when the switch is powered-up), irrespective of whether there is a call that presently needs to be sent through the trunk. Similarly, the trunk is not necessarily torn down merely because no calls are presently using the connection. Rather, it typically is torn down based on other considerations (for example, when the switch is powered-down).
After the trunk connections (i.e., the permanent TCP and UDP connections) are opened, the data streams from the incoming calls are multiplexed onto the connections according to the transport protocol type. Thus, multiple TCP data streams are muliplexed onto the permanent TCP connection. Multiple UDP data streams are multiplexed onto the permanent UDP connection.
In one embodiment, when a call is made to a switch, the switch adds a header to the call data. The header includes, for example, relatively simple two-way call setup information and an identifier. The switch on the receiving end uses the identifier to demultiplex the incoming data on the trunk into the individual streams of data for each of the calls.
In another embodiment, the switches provide multiple IP trunks to handle the call traffic. Yet, typically, the number of trunks is significantly smaller than the number of calls. As above, the switches do not perform TCP/UDP call setup and monitoring for each call. Instead, each call is multiplexed onto one of the trunks using simplified call setup procedures. The calls are multiplexed according to selected call distribution criteria.
The invention thus provides a way to achieve more efficient data transfer and to use the resources of the switches and the network more efficiently. The simplified call setup procedure for each call reduces the call setup time. The routing of multiple calls through a single trunk (or relatively few trunks) results in less overhead being required for each call, thereby reducing network traffic and bandwidth requirements. Moreover, the switches do not monitor each individual call. Rather, they only monitor the trunks (i.e., the permanent TCP and UDP connections). Thus, a system constructed according to the invention may use the processing resources of the switches more efficiently in comparison to many conventional systems.